Still working on testing a bit, but thought I'd throw this into review before the holiday.

IIUC, this is for computing the key "string" for recentMessageEntries. I don't think this needs any of the special formatting?

Two remarks:

• If we're going to use this method for creating a special/unique key, let's not call it a String method. For all of the reasons you wrote above -- the consumer of this method requires some crucial properties (great job describing them!). A method named String generally is assumed to not be bound by such strict requirements.
• But more preferably -- I'm a little concerned about the performance impact of this. More about the number of small allocations rather than CPU time. I'd recommend looking into the hashing functionality Go provides to create a unique identifier for a LogEntry.
  • I don't need to see a benchmark, but I think* Go makes it easy to do memory allocation benchmarks with the -benchmem flag. It that sounds like fun.

For what it's worth -- this can be computed before acquiring the lock. I don't expect that to a notable impact in the grand scheme of things. But that is a common technique in this type of scenario

I get why we use this name for the config flag (we want this to be on for robots by default), but I'm curious if you gave any consideration and/or had a reason why this global shouldn't be EnableLogDeduplication/DeduplicateLogs? The two benefits I see:

• Easier to read symbols in predicates that are in the affirmative
• The "least surprising behavior" (to a programmer) is for deduplication to be off. I think it's going to be more common to add tests that do not want deduplication. And moreover forget* it's happening. And tests that do need deduplication will know to turn it on.

I think* this could global variable could instead, without loss of generality, be put on the logger registry object? "Registry" certainly doesn't sound like the right name, but I think it's global enough for our purposes. And it would isolate the value for tests.